Method and Apparatus for Controlling an Sctp Protocol Instance

ABSTRACT

The invention relates to a network node (NN) comprising a first SCTP protocol instance (PI) providing redundancy of an SCTP endpoint the first SCTP protocol instance (PI) is connectable to a peer SCTP protocol instance via an SCTP connection (C 1 ). Furthermore the first SCTP protocol instance is connectable to a further SCTP protocol instance providing redundancy of the SCTP endpoint via a consistency protocol for providing state consistency between the first SCTP protocol instance and the further SCTP protocol instance and via a connection for forwarding messages addressed to the further protocol instance to be processed by the first protocol instance or vice versa.

FIELD OF INVENTION

The invention concerns a method for controlling an SCTP (Stream ControlTransmission Protocol) protocol instance associated with a redundantlyimplemented SCTP endpoint and to a related network node.

DESCRIPTION OF PRIOR ART

The invention relates to protocol instances of the SCTP protocol thathas been standardized in the RFC (request for comments) 2960 by the IETF(Internet Engineering Task Force). Network nodes comprising an SCTPprotocol instance usually comprise also protocol instances of a userapplication of the SCTP protocol, i.e. an application server or anapplication client that uses the SCTP protocol as a transport protocol.The communication partners of an SCTP connection are also termed SCTPendpoints. Peer application protocol instances of the applicationprotocol may communicate via APDUs (Application Protocol Data Units)that are transmitted using established SCTP associations.

An example for an application protocol that uses a transmission via theSCTP protocol is the M3UA (Message Transfer Part layer 3 User Agent)that is used for SIGTRAN i.e. signaling transmission over IP (InternetProtocol) networks.

To provide conversion between signaling messages sent via SIGTRAN andsignaling messages sent via a traditional SS7 (signaling system number7) network, signaling gateways have been developed that provideconversion between MTP3 (Message Transfer Part layer 3) messages andM3UA messages.

Such signaling gateways and other network nodes hosting SCTP userapplications may be a potential single point of failure, i.e. a singleinstance in a communication network, that, if failed, causes a largearea of the communication network to become inoperable.

OBJECT OF THE INVENTION

Therefore it is object of the invention to provide redundancy of an SCTPendpoint and by this also for SCTP user protocol endpoints.

SUMMARY OF THE INVENTION

This object is achieved by the network node according to claim 1 and themethod for controlling an SCTP protocol instance of claim 7.Advantageous embodiments are described in the dependent claims.

According to the invention a network node is provided that comprises afirst SCTP protocol instance providing redundancy of an SCTP endpoint,wherein the first SCTP protocol instance is connectable to a peer SCTPprotocol instance via an SCTP connection. The first SCTP protocolinstance is further connectable to a further SCTP protocol instanceproviding redundancy of the SCTP endpoint via a consistency protocol forproviding state consistency between the first SCTP protocol instance andthe further SCTP protocol instance and via a connection for forwardingmessages addressed to the further protocol instance to be processed bythe first protocol instance or vice versa.

By this redundancy is provided and both the first and the further SCTPprotocol instance may be available for receiving and processing SCTPmessages.

In an advantageous embodiment of the network node a first transportaddress is assigned to the first SCTP protocol instance, a furthertransport address is assigned to the further SCTP protocol instance andthe first and the further transport address are configured in thenetwork node such that they are both comprised in a set of transportaddresses assigned to the SCTP endpoint.

By this the redundant implementation of the SCTP endpoint does not needto be known at the peer SCTP protocol instance. The peer SCTP protocolinstance may use existing procedures described in the RFC 2960 of theIETF to select among the SCTP addresses associated with the SCTPendpoint an actual SCTP address to be included in an SCTP message.

In a further embodiment of the network node an active and an idle modeof operation are defined for the first SCTP protocol instance. In theactive mode of operation SCTP messages are actively processed by thefirst SCTP protocol instance and in the idle mode of operation SCTPmessages are forwarded to the further SCTP protocol instance.

By this flexibility is provided when handling SCTP messages.

In a another advantageous embodiment the network node comprises adecision unit for deciding according to a message type associated with areceived SCTP message whether to forward the received SCTP message ornot.

By this further flexibility is provided when handling SCTP messages.When configuring the message types efficiency or reliabilityconsiderations may be taken into account.

In a further advantageous embodiment of the network node it comprises astate supervision unit for supervising a state of availability of thefurther SCTP protocol instance as to whether the SCTP protocol instanceis available for processing SCTP messages. In this embodiment thenetwork node comprises a control unit for changing the mode of operationof the first protocol instance from the idle to the active mode or viceversa according to a result of the supervising the state of availabilityof the further SCTP protocol instance.

By this always one SCTP protocol instance can be provided that is in theactive mode of operation.

In another advantageous embodiment of the invented network node thefirst protocol instance is connectable to a plurality of furtherprotocol instances, and the network node comprises a configuration tablefor preconfiguring the control unit as to change the mode of operationof the first protocol instance according to a plurality of states ofavailability of the respective further protocol instances.

Thus, a unit that is comprised in the respective network node canprovide the decision, which SCTP protocol instance should switch intothe active mode of operation. Thus no further instance that may be asingle point of failure is needed for said decision-making.

According to a further aspect of the invention a method is provided forcontrolling an SCTP protocol instance associated with a redundantlyimplemented SCTP endpoint. The method comprises the following stepsperformed by the SCTP protocol instance:

receiving from a further SCTP protocol instance associated with the SCTPendpoint state information for providing state consistency between thefirst and the further SCTP protocol instance, and

adapting a state of the SCTP protocol instance according to the receivedstate information.

According to an advantageous embodiment the method comprising theadditional step of forwarding an SCTP message received from a peer SCTPprotocol instance to the further SCTP protocol instance associated withthe SCTP endpoint.

According to a further embodiment of the invented method an active andan idle mode of operation of the SCTP protocol instance are defined andthe method comprises determining an actual status of the mode ofoperation of the SCTP protocol instance, and deciding to perform theaforementioned steps in the idle mode of operation,

According to another advantageous embodiment of the invention a methodis provided for controlling an SCTP protocol instance associated with aredundantly implemented SCTP endpoint. The method comprises thefollowing steps performed by the SCTP protocol instance:

receiving a message originally sent by a peer SCTP protocol instancefrom a further SCTP protocol instance providing redundancy of the SCTPendpoint, processing the received SCTP message,

determining a state change of the SCTP protocol instance resulting fromthe processing of the SCTP message, and sending state informationassociated with the state change to the further SCTP protocol instance.

According to a further embodiment of the method in that an active and anidle mode of operation are defined, the method comprises deciding toperform the latter steps in the active mode of operation.

This provides a flexible method for message handling.

In a further embodiment of the invented method it comprises decidingaccording to a message type whether to process or to forward a receivedSCTP message.

By this another flexible method for message handling is provided. Whenconfiguring the message types efficiency or reliability considerationsmay be taken into account.

According to a further advantageous embodiment of the invented method itcomprises a step of receiving an indication of a state of availabilityof the further SCTP protocol instance and deciding to switch the mode ofoperation of the SCTP protocol instance from the active to the idle modeor vice versa according to the received indication of the state ofavailability of the further SCTP protocol instance.

By this always one SCTP protocol instance can be provided that is in theactive mode of operation.

According to a further advantageous embodiment of the invented methodthe SCTP protocol instance receives multiple indications of states ofavailability of respective further protocol instances, and the step ofdeciding to switch the mode of operation is based on a preconfiguredtable and on said multiple states of availability of the respectivefurther protocol instances.

Thus, a unit that is associated with the SCTP protocol instance canprovide the decision, which SCTP protocol instance should switch intothe active mode of operation. Thus no further instance that may be asingle point of failure is needed for said decision-making.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a network node according to the invention.

FIG. 2 depicts a sequence of message and processing steps that areexchanged according to the invention.

FIG. 3 depicts a first and a second network node hosting a redundantlyimplemented SCTP endpoint.

FIG. 4 depicts signalling messages and processing steps during a startup phase of a redundantly implemented SCTP endpoint

FIG. 5 depicts signalling messages and processing steps for a mutualsupervision of a status of availability

FIG. 6 depicts messages and processing steps during operation of aredundantly implemented SCTP endpoint

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 depicts a network node NN according to a preferred embodiment ofthe invention. The network node comprises a first SCTP protocol instancePI that is associated with a redundantly implemented SCTP endpoint. Thefirst SCTP protocol instance PI is connectable to a peer SCTP protocolinstance via an SCTP connection C1. The first SCTP protocol instance PIis further connectable via a further connection C2 to a further SCTPprotocol instance that is associated with the redundantly implementedSCTP endpoint. Both the first SCTP instance PI and the further SCTPprotocol instance are connected to the peer SCTP protocol instance viaone SCTP association. The further connection C2 comprises a connectionvia a consistency protocol for providing state consistency between thefirst SCTP protocol instance C1 and the further SCTP protocol instance.The further connection C2 also comprises a connection for forwardingmessages addressed to the further protocol instance to be processed bythe first protocol instance or vice versa. Though for illustrationalpurposes only one further connection C2 is depicted for both, forwardingmessages and providing state consistency information, separateconnections may be provided for each of the tasks. Though for simplicityonly the first and the further SCTP protocol instances are mentioned, aplurality of three or more SCTP protocol instances may be provided forthe redundantly implemented SCTP endpoint.

The network node NN may further comprise a control unit CU, aconfiguration table CT1, a priority list CT2, a state supervision unitSSU, and a decision unit DU, all of them interconnected and all of themconnected to the first SCTP protocol instance PI. Said units may beembodied in hardware, in software or in a combination thereof.

A first transport address may be assigned to the first SCTP protocolinstance, a further transport address may be assigned to the furtherSCTP protocol instance and the first and the further transport addressmay be configured in the configuration table such that they both relateto a set of transport addresses assigned to the SCTP endpoint.

Advantageously for the first SCTP protocol instance PI an active and anidle mode of operation are defined, wherein in the active mode ofoperation SCTP messages are actively processed by the first SCTPprotocol instance and in the idle mode of operation SCTP messages areforwarded to via the first connection C1 to the further SCTP protocolinstance.

The decision unit DU may be provided for deciding according to a messagetype associated with a received SCTP message whether to forward areceived SCTP message or not.

The state supervision unit SSU may be provided for supervising a stateof availability of the further SCTP protocol instance as to whether theSCTP protocol instance is available for processing SCTP messages. Thecontrol unit CU may be provided for changing the mode of operation ofthe first SCTP protocol instance PI from the idle to the active mode orvice versa according to a result of the supervising the state ofavailability of the further SCTP protocol instance. According to thechanging of the mode of operation of the first SCTP protocol instance PIthe control unit CU may initiate a respective change of a mode ofoperation of a further SCTP protocol instance as well. E.g. if the modeof operation of the first protocol instance is switched to the activemode of operation, this may be indicated to a further SCTP protocolinstance, such that it may switch its mode of operation to idle.

E.g. the state supervision unit SSU may be adapted to receive signalsindicating a state of availability from the further SCTP protocolinstance. Said signals may be sent on request by the state supervisionunit. If a signal indicates that the further SCTP protocol instance isnot available for processing SCTP messages, the control unit may changethe mode of operation of the first SCTP protocol instance from the idlemode to the active mode. If a later received signal indicates that thefurther SCTP protocol instance is available for processing SCTP messagesagain, the control unit may change the mode of operation from the activemode to the idle mode.

The first SCTP protocol instance PI1 may be connectable to a pluralityof further SCTP protocol instances and the priority list CT2 maypreconfigure the control unit as to change the mode of operation of thefirst protocol instance PI according to a plurality of states ofavailability of the respective further protocol instances. E.g. thepriority list CT2 may be ranked according to an order indicating when toswitch from an idle to an active mode of operation. The control unit CUmay change the mode of operation from the idle to the active mode ofoperation, when the state supervision unit has indicated that the higherranked further SCTP protocol instances are not available for processingSCTP messages.

FIG. 2 depicts a sequence of messages and processing steps that areperformed in a preferred embodiment of the invention. The figure depictsa first SCTP protocol instance PI1 and a second SCTP protocol instancePI2, both of them associated with a redundantly implemented SCTPendpoint. FIG. 2 further depicts a peer SCTP protocol instance PPI thatcommunicates with the SCTP endpoint. Both the first and the second SCTPprotocol instance PI1 and PI2 are connected to the peer SCTP protocolinstance PPI via one SCTP association. Though for simplicity only thefirst and the second SCTP protocol instance PI1 and PI2 are depicted,further SCTP protocol instances that are associated with the redundantlyimplemented SCTP endpoint may be provided

The sequence of messages is initiated when the first SCTP protocolinstance PI1 receives a first SCTP message M1 from the peer SCTPprotocol instance PPI.

The first SCTP protocol instance PI1 may be in active or in an idle modeof processing SCTP messages. Accordingly, the second SCTP protocolinstance PI2 may be in an idle or active mode of operation, i.e. in adifferent mode of operation than the first SCTP protocol instance PI1.

Upon reception of the SCTP message a first decision step DS1 may beperformed in the first SCTP protocol instance or in a decision unit thatis associated with the first SCTP protocol instance. In the firstdecision step DS1 a decision is taken whether to actively process afirst SCTP message or to forward the first SCTP message to the secondSCTP protocol instance PI2.

The decision step DS1 may be based on the message type of the first SCTPmessage M1.

Alternatively or in addition the decision step DS1 may be based on amode of operation of the first SCTP protocol instance PI1. I.e. anactive and an idle mode of operation may be defined and in the activemode of operation the decision taken in the first decision step DS1 isto actively process the received first SCTP message M1 whereas in theidle mode of operation the decision taken in the first decision step DS1is to forward the received first SCTP message to the second SCTPprotocol instance PI2, which in the active mode of operation. If aplurality of further SCTP protocol instances is provided, a particularone of the plurality of further SCTP protocol instances that is in theactive mode of operation is selected and the received SCTP message isforwarded to the selected active SCTP protocol instance.

The mode of operation may be chosen according an indication MO of astate of availability of the second SCTP protocol instance PI2, that hasbeen previously received from the second SCTP protocol instance PI2.Based on that indication a decision to switch the mode of operation ofthe SCTP protocol instance from the active to the idle mode or viceversa may be taken. I.e. if the indication MO indicates anunavailability of the second SCTP protocol instance PI2, the first SCTPprotocol instance should switch to the active mode of operation, whereasif the indication MO indicates that the second SCTP protocol instance isavailable for processing SCTP messages the first SCTP message may switchto the idle mode of processing.

The first protocol instance PI1 may be connectable to a plurality offurther SCTP protocol instances from which a respective indication of astate of availability has been previously received and a priority listmay be preconfigured to chose the mode of operation of the firstprotocol instance PI according to a plurality of states of availabilityof the respective further protocol instances. E.g. the priority list maybe a sorted list of further SCTP protocol instances, which are rankedaccording to an order indicating when to switch from an idle to anactive mode of operation. The mode of operation may be changed from theidle to the active mode of operation, when indications have beenreceived that the higher ranked further SCTP protocol instances are notavailable for processing SCTP messages.

If the decision taken in the decision step DS1 has been to activelyprocess the first SCTP message the first SCTP message M1 is processed bythe first SCTP protocol instance in a first processing step PS1, and astate change of the SCTP protocol instance resulting from the processingof the SCTP message is determined in a second processing step PS2. Stateinformation associated with the state change is sent to the second SCTPprotocol instance in a second message M2. The second SCTP protocolinstance PI2 adapts its state according to the received stateinformation in a third processing step PS3.

If the decision taken in the decision step DS1 is to forward the firstSCTP message, the first SCTP message M1 is forwarded to the further SCTPprotocol instance PI2 in the forwarded SCTP message M3.

The forwarded SCTP message M3 is processed in the second SCTP protocolinstance PI2 in a fourth processing step PS4 and a state changeresulting from the processing of the SCTP message is determined in afifth processing step PS5. State information associated with the statechange is sent to the first SCTP protocol instance in a fourth messageM4. The first SCTP protocol instance adapts its state according to thereceived state information in a sixth processing step PS6.

FIG. 3 depicts a first and a second node N1 and N2 hosting a redundantlyimplemented SCTP endpoint. A first SCTP protocol instance SPI1 and asecond SCTP protocol instance SPI2 are both associated with theredundantly implemented SCTP endpoint. The first SCTP protocol instanceSPI1 is connected to a first IP protocol instance IPPI1 that is attachedto the IP network IPN. The first SCTP protocol instance is furtherconnected to a first application protocol instance API1. The firstapplication protocol instance API1, the first SCTP protocol instanceSPI1 and the first IP protocol instance IPPI1 are implemented on thefirst node N1.

Accordingly the second SCTP protocol instance SPI2 is connected to asecond IP protocol instance IPPI2 that is attached to the IP networkIPN. The second SCTP protocol instance is further connected to a secondapplication protocol instance API2. The second application protocolinstance API2, the second SCTP protocol instance SPI2 and the second IPprotocol instance IPPI1 are implemented on a second node N2.

Though only two SCTP protocol instances are depicted for illustrationalpurposes, a plurality of three or more SCTP protocol instances may beprovided for a redundantly implemented SCTP endpoint.

The layers involved in the nodes are shown as well, consisting of theIP, SCTP and application layer.

The first IP protocol instance is addressable from the IP network IPNusing the IP addresses IP1 and IP2 and accordingly the second IPprotocol instance is addressable from the IP network IPN using the IPaddresses IP3 and IP4.

The first and the second SCTP protocol instance SPI1 and SPI2 areinterconnected via a SCTP consistency protocol CPS, that provides astate consistency between the first and the second SCTP protocolinstance SPI1 and SPI2.

The first and the second SCTP protocol instance SPI1 and SPI2 offertransport addresses to the first and the second application protocolinstance API1 and API2 respectively.

Both the first and the further SCTP instance SPI1 and SPI2 are connectedto a peer SCTP protocol instance via one SCTP association, but usedifferent transport addresses for that.

In particular the transport addresses TA1 and TA2 are associated withthe first SCTP protocol instance SPI1 and the transport addresses TA3and TA4 are associated with the second SCTP protocol instance SPI2. Thefirst and the second SCTP protocol instance SPI1 and SPI2 are alsotermed SCTP protocol instances of the redundantly implemented SCTPendpoint.

Each set of transport addresses in a node is associated with a SCTPprotocol instance of the redundantly implemented SCTP end point. Thetransport addresses TA1, TA2, TA3 and TA4 are associated with the IPaddresses IP1, IP2, IP3 and IP4 respectively in that each transportaddress is composed of a respective IP address and a port number. E.g.the transport address TA1 comprises the IP address IP1 and a respectiveport number. The redundantly implemented SCTP end point is addressablevia the transport addresses TA1, TA2, TA3, and TA4.

A changeable mode of operation is assigned to each SCTP protocolinstance of the redundantly implemented SCTP endpoint. In the depictedexample an active mode of operation is currently assigned to the firstSCTP protocol instance SPI1, and an idle mode of operation is currentlyassigned to the second SCTP protocol instance SPI2. However the activeand the idle mode of operation are assignable to both, the first and thesecond SCTP protocol instance SPI1 and SPI2.

The first SCTP protocol instance SPI1, which is in the active mode ofoperation actively processes SCTP traffic. The second SCTP protocolinstance SPI2, which is in the idle mode of operation forwards SCTPtraffic that is addressed to one of its transport addresses TA3 and TA4to the first SCTP protocol instance SPI1.

State consistency between the first and the second SCTP protocolinstance SPI1 and SPI2 is provided by an SCTP consistency protocol CPSvia which information describing a state change may be transmittedbetween the first and the second SCTP protocol instance SPI1 and SPI2.Upon processing an SCTP data chunk at the first SCTP protocol instanceSPI1, a state change of the first SCTP protocol instance resulting fromthe processing of the data chunk is determined and informationdescribing the state change is transmitted from the first to the secondSCTP protocol instance, i.e. from SPI1 to SPI2. By this stateconsistency between the first and the second SCTP protocol instance SPI1and SPI2 is provided for and the second SCTP protocol instance SPI2 isprepared to switch from the idle mode of operation to the active mode ofoperation.

Furthermore the first and the second SCTP protocol instance SPI1 andSPI2 are interconnected to transmit forwarded SCTP chunks that arereceived on a transport address associated with the idle SCTP protocolinstance, but that should be processed by the active SCTP protocolinstance.

The second SCTP protocol instance, which is in the idle mode ofoperation may apply a selective processing of received SCTP chunks inthat a first kind of SCTP chunks are actively processed and a secondkind of SCTP data chunks is not actively processed but forwarded to thefirst SCTP protocol instance SPI1, which is in the active mode ofoperation.

E.g. control chunks may not be actively processed in the idle mode ofoperation and DATA and ACK chunks may be actively processed also in theidle mode of operation.

For control chunks the inactive SCTP protocol instances rely on thefirst SCTP protocol instance that is in the active mode of operation forproviding the information describing the state change resulting fromprocessing the control chunks.

By this the processing of data may be performed only at the first SCTPprotocol instance, which is in the active SCTP protocol instance, and aparallel processing at the second SCTP protocol instance that is in theidle mode of operation may be avoided This reduces the total amount ofneeded processing power and this reduces the risk of mismatches betweenthe first and the second SCTP protocol instance.

Processing DATA and SACK chunks at both the first and the second SCTPprotocol instance SPI1 and SPI2 reduces the traffic between the SCTPprotocol instances.

Accordingly state consistency between the first and the secondapplication protocol instance API1 and API2 may be provided by anapplication consistency protocol CPAP.

Advantageously the SCTP consistency protocol CPS, the applicationconsistency protocol CPAP, and the connection for forwarding SCTP chunksbetween the first and the second SCTP protocol instance SPI1 SPI2 shouldutilize a connection that is separate from the respective connectiontowards the IP network. By this an exchange of messages between thefirst and the second node N1 and N2 may be such that it is not disturbedby a failure within the IP network.

A set of transport addresses TA1, TA2, TA3, and TA4 are associated withthe SCTP endpoint and by that the redundantly implemented SCTP endpointis a multihomed SCTP endpoint. The set of transport addresses is madeknown to each peer SCTP protocol instance that is communicating with theSCTP endpoint. By that each of the transport addresses TA1, TA2, TA3,and TA4 may be used by a peer SCTP protocol instance when addressing theSCTP endpoint.

However the structure of the redundantly implemented SCTP endpoint doesnot need to be taken into account when configuring a peer SCTP protocolinstance.

The peer SCTP protocol instance will perform the normal fail-over andre-transmission procedures between the different transport addressesTA1, TA2, TA3, and TA4 associated with the redundantly implemented SCTPendpoint. By that, disturbances in the communication between the SCTPendpoint and its peer protocol instances may be handled.

An SCTP messages addressed to a SCTP protocol instance of the SCTPendpoint that is down is lost and is subject to re-transmission to analternative transport address by the peer SCTP protocol instance. Thealternative transport address is determined by the peer SCTP protocolinstance and will eventually belong to one of the idle SCTP protocolinstances or the active SCTP protocol instance.

FIG. 4 depicts a sequence of messages and processing steps that areexchanged between a first SCTP protocol instance EPZ1 and a second SCTPprotocol instance EPZ2 that are associated with a redundantlyimplemented SCTP endpoint. When the redundantly implemented SCTPendpoint is created, the first and the second SCTP protocol instanceEPZ1 and EPZ2 are informed about the existence of the respective otherSCTP protocol stance and addressing information enabling addressing therespective other SCTP protocol instance has to be provided. Thisinformation may be preconfigured in the first and in the second SCTPprotocol instance EPZ1 and EPZ2 or the information may be exchanged in astart up phase of the redundantly implemented SCTP endpoint. To that endmessages may be exchanged via a consistency protocol providing stateconsistency between the first and the second SCTP protocol instance EPZ1and EPZ2.

FIG. 4 depicts a start up phase of the redundantly implemented SCTPendpoint, in that the first SCTP protocol instance FPZ1 performs a startup process SU1 and sends a notification message NM1 to the second SCTPprotocol instance EPZ2, the notification message NM1 comprising a set ofaddresses via which the first SCTP protocol is addressable and a thenotification message comprising a priority list indicating when thefirst SCTP protocol instance will switch into an idle mode of processingrespectively in an active mode of processing. If all SCTP protocolinstances that have been assigned a higher priority within theprioritised list have gone down, the SCTP protocol instance that hasbeen assigned the next lower priority will change its mode of operationto the active mode of operation. Upon reception of the notificationmessage the second SCTP protocol instance performs a processing step PA2and stores the set of addresses and the priority list received in thenotification message NM1.

Accordingly the second SCTP protocol instance performs a start up phaseSU2, sends a notification message NM2 comprising addressing informationand a priority list structured as described above to the first SCTPprotocol instance EPZ1, and the first SCTP protocol instance EPZ2performs a processing step PA1 in that it stores the addressinginformation and the priority list previously received in thenotification message NM2

FIG. 5 depicts a sequence of messages exchanged between the first andthe second SCTP protocol instance EPZ1 and EPZ2 as well as processingsteps that are performed at the first and the second protocol instanceEPZ1 and EPZ2. The purpose of the depicted processing steps andexchanged messages is to mutually supervise the state of the respectiveother SCTP protocol instances and to detect a failure condition at therespective other SCTP protocol instance.

In particular an SCTP protocol instance that is in an idle mode ofoperation needs to know the status of each other SCTP protocol instance,i.e. whether it is operable and if it is operable whether is in an idleor in an active mode of operation.

The first and the second SCTP protocol instance are regularly exchangingnotification messages termed ‘hello’ messages, that notify therespective other SCTP protocol instance about a status of availabilityof the sending SCTP protocol instance. The notification messages have tobe acknowledged within a certain time interval. The reception of anacknowledgement sent in response to an earlier sent notification messagemay be treated as indication that the SCTP protocol instance that hassent the acknowledgement message is operable as well.

Each SCTP protocol instance broadcasts notification messages at periodictime intervals. A notification message contains a unique identificationthat is associated with the respective SCTP protocol instance. An SCTPprotocol instance a notification message will mark the respective SCTPprotocol instance that has sent the notification message as operable or‘alive’.

An SCTP protocol instance that has lost the connectivity to anassociated application layer protocol instance or to an associated IPprotocol instance, but is still capable of communicating with the otherSCTP protocol instances associated with the redundantly implemented SCTPendpoint, preferably should not send any notification message until theconnectivity to the associated application layer protocol instance isre-established. Furthermore, if such an SCTP protocol instance is in anidle mode of operation it should preferably not be switched into anactive mode of operation.

When a notification message from a particular SCTP protocol instance isreceived by another SCTP protocol instance within a certain timeinterval, the other STP protocol instance will mark the respective asinoperable or “down”.

An SCTP protocol instance that has recovered and becomes operable (or“up”) again will first be in an idle mode of operation. It will start tobroadcast notification messages, indicating that it is operable, thenotification message comprising an identification of the sendingrecovered SCTP protocol instance. By this other SCTP protocol instancesthat are operable may detect that the recovered SCTP protocol instanceis available again.

Based on the status marking of each SCTP protocol instance received in anotification message, an SCTP protocol instance may take the necessarydecisions on to which mode of operation, i.e. the idle mode of operationor the active mode of operation, to switch to based on the previouslyexchanged priority lists.

In the following the sequence of messages exchanged between the firstand the second SCTP protocol instance EPZ1 and EPZ2 and respectiveprocessing steps that are performed at the first and the second protocolinstance EPZ1 and EPZ2 will be described in detail.

The first SCTP protocol instance EPZ1 sends a first ‘hello’-message HM1to the second SCTP protocol instance EPZ2. The purpose of the first‘hello’-message HM1 is to indicate that the first SCTP protocol instanceEPZ1 is operable and capable of processing SCTP messages. The secondSCTP protocol instance EPZ2 receives the first ‘hello’-message HM1,processes the first ‘hello’-message HM1 in a processing step PS04 andupon said processing, the first SCTP protocol instance EPZ1 marks thesecond SCTP protocol instance EPZ2 as operable or ‘alive’.

Upon sending the first ‘hello’-message HM1, the first SCTP protocolinstance starts a supervision timer for supervising the second SCTPprotocol instance EPZ2 in a processing step PS01. If an acknowledgementmessage with respect to the first ‘hello’ message HM1 is not receivedwithin a predetermined time interval, the first SCTP protocol instanceEPZ1 marks the second SCTP protocol instance EPZ2 as inoperable, i.e. asnot capable of processing SCTP messages.

Upon processing the first hello message ITM1, the second SCTP protocolinstance FPZ2 sends a first acknowledgement message HA1 with respect tothe first ‘hello’ message HM1 to the second SCTP protocol instance EPZ2.If the first acknowledgement message HA1 is received within apredetermined time interval in the first SCTP protocol instance EPZ1,the first SCTP protocol instance EPZ1 marks the second SCTP protocolinstance EPZ2 as operable in a processing step PS02.

Accordingly the second SCTP protocol instance EPZ2 sends a second‘hello’-message HM2 to the first SCTP protocol instance EPZ1 to indicatethat the second SCTP protocol instance EPZ2 is operable and capable ofprocessing SCTP messages. The first SCTP protocol instance EPZ1 receivesthe second ‘hello’-message HM2, processes the second ‘hello’-message HM2in a processing step PS03 and upon said processing, the second SCTPprotocol instance EPZ2 marks the first SCTP protocol instance EPZ2 asoperable or ‘alive’.

Upon sending the second ‘hello’-message HM2, the second SCTP protocolinstance starts a supervision timer for supervising the first SCTPprotocol instance EPZ1 in a processing step PS05. If an acknowledgementmessage with respect to the second ‘hello’ message HM2 is not receivedwithin a predetermined time interval, the second SCTP protocol instanceEPZ2 marks the first SCTP protocol instance EPZ1 as inoperable, i.e. asnot capable of processing SCTP messages.

Upon processing the second hello message HM2, the first SCTP protocolinstance EPZ1 sends a second acknowledgement message HA2 with respect tothe second ‘hello’ message HM2 to the first SCTP protocol instance EPZ1.If the second acknowledgement message HA2 is received within apredetermined time interval in the second SCTP protocol instance EPZ2,the second SCTP protocol instance EPZ2 marks the first SCTP protocolinstance EPZ1 as operable or ‘alive’ in a processing step PS06.

FIG. 6 depicts a sequence of messages and processing steps performed ata distributed SCTP endpoint that acts as a server process. In thefollowing description a reference is made to the RFC 2960 and to theestablishment of SCTP associations and the message and data transferdescribed therein.

SCTP Association Management

The SCTP protocol instances associated with a redundantly implementedSCTP endpoint need to exchange state information in order to pertain acommon state.

In particular, when an SCTP protocol instance which is in an active modeof operation receives SCTP messages and SCTP chunks directly, i.e. if anSCTP message or an SCTP chunk has not been forwarded by an SCTP protocolinstance that is in an idle mode of operation, then the SCTP protocolinstance that is in the active mode of operation has to inform SCTPprotocol instances that are in the idle mode of operation about acurrent state that is an outcome of processing the message or the datachunk. This may be performed by sending a respective message via a stateconsistency protocol.

When an SCTP protocol instance that is in an idle mode of operation hasforwarded an SCTP message to the SCTP protocol instance that is in theactive mode of operation, the SCTP protocol instance that is in theactive mode of operation has to inform the SCTP protocol instances thathave not received the SCTP message about the current state of the activeSCTP protocol instance and the related data.

As the communication of the state information providing stateconsistency among the SCTP protocol instances associated with theredundantly implemented SCTP endpoint is vital for the operation of theredundantly implemented SCTP endpoint, state information is preferablytransmitted reliably via the consistency protocol. This may be achievedby transmitting the state information on a reliable medium that issolely used for this purpose in order to avoid disturbances by othertraffic between the SCTP protocol instances associated with theredundantly implemented SCTP endpoint.

SCTP Association Establishment: the Redundantly Implemented SCTPEndpoint Acts as a Server

In the following it is assumed that the redundantly implemented SCTPendpoint acts as a server process i.e. an SCTP user process isregistered with SCTP under the redundantly implemented SCTP endpoint andthe SCTP user process is ready for communication with a remote peer SCTPuser process, but it will not take the initiative to establish anycommunication on its own. The redundantly implemented SCTP endpointcomprises a first SCTP protocol instance FPZ1, which is in an activemode of operation and a second SCTP protocol instance EPZ2, which is inan idle mode of operation.

INIT Received at Active Server SCTP Protocol Instance

During an establishment procedure of an SCTP association an SCTP INITmessage IM1 is received at an SCTP address associated with the firstSCTP protocol instance EPZ1 from a peer SCTP protocol instance. Thereception of the SCTP INIT message IM1 is acknowledged in an SCTP INITACK message IMA1.

In the following the IP address associated with the first SCTP protocolinstance EPZ1 is termed IP1.

The active first SCTP protocol instance EPZ1 sends a first stateconsistency message SM1 to the idle second SCTP protocol instance EPZ2.The purpose of the first state consistency message SM1 is to inform thesecond SCTP protocol instance EPZ2 about the INIT attempt. The firststate consistency message SM1 comprises the following data:

-   -   The Initiate Tag Tag_A (i.e. the value for the Verification Tag        in any outbound SCTP packet), that has been assigned by the peer        SCTP protocol instance.    -   Advertised Receiver Window Credit a_rwnd that has been assigned        by the first SCTP protocol instance EPZ1 SCTP protocol instance.    -   The number of inbound and outbound streams used for this        association, i.e. the number of inbound and outbound streams        between the communicating SCTP end points that is intended to be        used as calculated according to RFC 2960, section 5.1.1.    -   Initial TSN (transaction sequence number) as used by the peer        SCTP protocol instance and the first SCTP protocol instance        EPZ1.    -   IPv4 and IPv6 addresses associated with the peer SCTP protocol        instance resulting from the address resolution as described in        RFC 2960, section 5.1.2.    -   Cookie Preservative.    -   The State Cookie that the first SCTP protocol instance EPZ1 will        reply in the SCTP INIT_ACK message IMA2. This ensures that the        second SCTP protocol instance EPZ2 can act on potentially        received COOKIE ECHOE messages.

When an SCTP COOKIE ECHOE message CM1 is received in the first SCTPprotocol instance EPZ1, the first SCTP protocol instance FPZ1 has toinform the second SCTP protocol instance EPZ1 whether the cookie isaccepted or not. For this purpose a second state consistency message SM2is sent from the first to the second SCTP protocol instance, i.e. fromEPZ1 to EPZ2. The reception of the COOKIE ECHOE message CM1 isacknowledged in an SCTP COOKIE ACK message CMA1.

Actions at the Idle Server SCTP Protocol Instances

In a processing step PS61 the second SCTP protocol instance EPZ2 storesthe data received in the first state consistency message SM1. Thus theidle second SCTP protocol instance EPZ2 is able to take over the role ofan active SCTP protocol instance, i.e. to switch to an active mode ofoperation with the aid of the data provided as described above.

The inactive second SCTP protocol instance EPZ2 is supposed to be in arelay (or proxy) mode per configuration, unless the active first SCTPprotocol instance EPZ1 is detected to be down and the inactive secondSCTP protocol instance EPZ2 is supposed to enter into the active mode ofoperation.

In the relay mode the second SCTP protocol instance EPZ2 will simplyrelay any SCTP messages received from the remote endpoint to the activefirst SCTP protocol instance EPZ1 via a communication path previouslyestablished for forwarding SCTP messages between the first and thesecond SCTP protocol instance, EPZ1 and EPZ2.

The assignment of a mode of operation, i.e. idle or active, to a SCTPprotocol instance, may be performed as follows:

Initially, any inactive SCTP protocol instance is in the CLOSED-I state(i.e. CLOSED state, IDLE mode).

If the idle SCTP protocol instance that is supposed to take over detectsthat the active SCTP protocol instance is out of service it shall nowbecome active and enter the association state ‘CLOSED’.

When the idle second SCTP protocol instance EPZ2 is informed that thecookie was accepted by the active SCTP protocol instance, i.e. when ithas received the second state consistency message SM2, then the secondSCTP protocol instance EPZ2 drops the stored cookie and enter the stateESTABLISHED-I in a processing step PS62.

SCTP Association Establishment: Distributed Endpoint Acts as a Client

In the following the SCTP Association Establishment will be describedfor a distributed endpoint that acts as a client process. This means, anSCTP user process is registered with SCTP under the defined SCTPendpoint and the SCTP user process requests SCTP to establish acommunication with a remote peer SCTP protocol instance.

INIT Sent from Active Client SCTP Protocol Instance

The SCTP INIT message is sent from one SCTP address belonging to a SCTPprotocol instance of the distributed SCTP end point. In the followingthis SCTP protocol instance sending the INIT message is considered to bethe active SCTP protocol instance.

In the following the SCTP endpoint acting as a client process will betermed endpoint A, whereas the SCTP end point acting as a client processwill be termed end point Z.

The active SCTP protocol instance has to inform idle SCTP protocolinstances about the INIT attempt, making these SCTP protocol instancesaware of the following data:

-   -   The Initiate Tag Tag_A (i.e. the value for the Verification Tag        in any outbound SCTP packet) as sent to end point Z.    -   Advertised Receiver Window Credit a rwnd as used by the active        SCTP protocol instance and sent to end point Z.    -   The number of inbound and outbound streams as intended for this        association, i.e. the number of inbound and outbound streams        that has originally been sent in the INIT chunk    -   An initial TSN (transaction sequence number) as used by the        active SCTP protocol instance of end point A.    -   Cookie Preservative.

The active SCTP protocol instance has to inform idle SCTP protocolinstances about the data received in the INIT ACK message:

-   -   The Initiate Tag Tag_Z (i.e. the value for the Verification Tag        in any outbound SCTP packet) assigned by end point Z.    -   Advertised Receiver Window Credit a_rwnd as given by end point        Z.    -   The number of inbound and outbound streams used for this        association i.e. the number of inbound and outbound streams        between the communicating SCTP end points that is intended to be        used as calculated according to RFC 2960, section 5.1.1.

The previously stored values that were valid when sending the INIT chunkmay be deleted by the idle SCTP protocol instances.

-   -   Initial TSN as used by end point Z.    -   IPv4 and IPv6 addresses valid for the remote EP resulting from        the address resolution as described in RFC 2960, section 5.1.2.    -   The State Cookie as received in the INIT_ACK.

When the COOKIE ECHOE is sent, the active SCTP protocol instance has toinform the idle SCTP protocol instances about the cookie sent to theremote end point.

When the COOKIE ACK is received from the remote end point, it indicatesto the idle SCTP protocol instance that it may close the cookieprocessing.

With the data exchanged as outlined above, the idle SCTP protocolinstances are able to take over the role of an active SCTP protocolinstance.

Actions at the Idle Client SCTP Protocol Instances

The idle SCTP protocol instance is supposed to be in a relay (or proxy)mode per configuration, unless the active SCTP protocol instance isdetected to be down and the inactive SCTP protocol instance is supposedto take over and consequently becomes active.

In the relay mode it will simply relay any SCTP messages received fromthe remote endpoint to the active SCTP protocol instance via thecommunication path established for aligning the two SCTP protocolinstances.

Initially, any idle SCTP protocol instance is in one of the statesCLOSED-I, COOKIE-WAIT-I, COOKIE-ECHOED-I. In this terminology the stateof the SCTP state machine according to RFC 2960 is followed by a suffixI indicating the IDLE mode.

If the idle SCTP protocol instance that is supposed to take over detectsthat the active SCTP protocol instance is out of service it shall nowbecome active and enter the corresponding active association state.

Data Transfer Phase

The data transfer phase refers to the SCTP states ESTABLISHED,ESTABLISHED-I, SHUTDOWN-PENDING, SHUTDOWN-PENDING-I, SHUTDOWN-RECEIVED,SHUTDOWN-RECEIVED-I, COOKIE-WAIT, COOKIE-WAIT-I, COOKIE-ECHOED,COOKIE-ECHOED-I, SHUTDOWN-SENT, and SHUTDOWN-SENT-I. Again, states withthe appendix “-I” refer to an idle state corresponding to an SCTPprotocol instance state. In this phase both ends can exchange data bymeans of sending DATA chunks and acknowledging the receipt of DATAchunks by SACK chunks.

Idle SCTP protocol instances will relay DATA and SACK chunks. On theother hand, they will buffer any DATA chunk until the chunk is indicatedas delivered to the ULP by either end of the communication. Buffering isdone in order to be able to take over the task of the active SCTPprotocol instance if a currently active SCTP protocol instance fails.

When an active SCTP protocol instance receives a DATA chunk, it willprocess the message according to the description in RFC 2960 section6ff.

When an idle SCTP protocol instance receives a DATA chunk, it willforward the DATA chunk to the currently active SCTP protocol instance.

The idle SCTP protocol instance will keep a copy of all DATA chunks ineither direction in a buffer until the condition for removing the chunkaccording to RFC 2960 is given. Normally the condition is given when thecumulative TSN ACK point indicated by a SACK chunk is set to a TSNhigher then the TSN of the DATA chunk in question.

The idle SCTP protocol instances will parse any incoming message forSACK chucks in order to keep track of acknowledged DATA chunks in eitherdirection (from and to the active SCTP protocol instance). When thecumulative TSN ACK point indicated by a SACK chunk is set to a TSNhigher then the TSN of the DATA chunk in the buffer, the chunk isremoved from the buffer.

Furthermore, the idle SCTP protocol instances will keep track about theadvertised receiver window credit a_rwnd.

Termination of Association

Abort of an Association

The active SCTP protocol instance may act on the receipt of an SCTPABORT message or when initiating an SCTP ABORT procedure in the same wayas described in RFC 2960. Additionally, it will send a messageindicating the reception or the initiation to all corresponding idleSCTP protocol instances. For this purpose the consistency protocolbetween the SCTP protocol instances may be used.

Idle SCTP protocol instances may clear all data related to anassociation upon reception of said indication.

Shutdown of an Association

The active SCTP protocol instance sends an indication to all idle SCTPprotocol instances when the shutdown procedure is completed and thelocal TCB (Transmission Control Block) is destroyed.

Advantageously idle SCTP protocol instances arc prepared to take overthe role of an active SCTP protocol instance during the shutdown phasein the same way as in the data transfer phase as the graceful close ofthe association may require a data transfer of outstanding DATA chunks.Previously kept state information may be deleted.

SCTP Protocol Instance Failover

Whenever an idle SCTP protocol instance detects the failure of theactive SCTP protocol instance, it has to check whether it has to takeover the role of the active SCTP protocol instance. The decision onwhether to take over the role of the active SCTP protocol instance maybe performed based on a preconfigured priority list as described above.

When a idle SCTP protocol instance detects that ConP(Hello) messages,i.e. indications of being operable sent according to the consistencyprotocol, are no longer received from the active SCTP protocol instance,or when the active SCTP protocol instance does not respond to aConP(Hello) message by sending a respective acknowledgement message,then it marks the active SCTP protocol instance as defective. Accordingto the preconfigured priority list, the previously idle SCTP protocolinstance may perform a decision to switch to an active mode ofoperation.

Upon changing the mode of operation to the active mode of operation, theSCTP protocol instance that has switched to the active mode of operationmay utilize the state information about the data exchange as computedfrom all previously exchanged data in its new the role of the activeSCTP protocol instance.

When the failed, previously active SCTP protocol instance becomesoperable again it indicates that it is operable by sending a ConP(Hello)to the currently active SCTP protocol instance. Upon reception of thisindication the currently active SCTP protocol instance indicates itsmode of operation to the previously active SCTP protocol instance.Furthermore the currently active SCTP protocol instance updates thepreviously active SCTP protocol instance with all needed data so that itcan potentially switch to an active mode of operation.

A SCTP protocol instance that recovers from a failure may assume thatanother SCTP protocol instance has switched into the active mode ofoperation. It may indicate that it is operable again by sending aConP(Hello) message as described above. Furthermore the recovered SCTPprotocol instance is prepared to receive an indication of a mode ofoperation and relevant state information from a currently active SCTPprotocol instance.

1-10. (canceled)
 11. A network node, comprising: a first Stream ControlTransmission Protocol (SCTP) protocol instance providing redundancy ofan SCTP endpoint; a peer SCTP protocol instance, wherein the first SCTPprotocol instance is connected to the peer SCTP protocol instance via anSCTP connection; a further SCTP protocol instance, wherein the firstSCTP protocol instance is further connected to the further SCTP protocolinstance providing redundancy of the SCTP endpoint via a consistencyprotocol for providing state consistency between the first SCTP protocolinstance and the further SCTP protocol instance and via a connection forforwarding messages addressed to the further protocol instance to beprocessed by the first protocol instance or vice versa; wherein for thefirst SCTP protocol instance, an idle mode of operation is defined, andin the idle mode of operation, SCTP messages are forwarded to thefurther SCTP protocol instance; and wherein the network node includes adecision unit for deciding, when the SCTP protocol instance is in theidle mode of operation, according to a message type associated with areceived SCTP message, whether or not to actively process the receivedSCTP message.
 12. The network node according to claim 11, wherein afirst transport address is assigned to the first SCTP protocol instance,a further transport address is assigned to the further SCTP protocolinstance, and the first and the further transport address are configuredin the network node such that they are both included in a set oftransport addresses assigned to the SCTP endpoint.
 13. The network nodeaccording to claim 11, wherein for the first SCTP protocol instance, anactive mode is defined in which SCTP messages are actively processed bythe first SCTP protocol instance.
 14. The network node according toclaim 13, further comprising: a state supervision unit for supervising astate of availability of the further SCTP protocol instance as towhether the SCTP protocol instance is available for processing SCTPmessages; and a control unit for changing the mode of operation of thefirst protocol instance from the idle to the active mode or vice versaaccording to a result of supervising the state of availability of thefurther SCTP protocol instance.
 15. The network node according to claim14, wherein the first protocol instance is connected to a plurality offurther protocol instances, and wherein the network node includes aconfiguration table for preconfiguring the control unit to change themode of operation of the first protocol instance according to aplurality of states of availability of the respective further protocolinstances.
 16. A method of controlling a Stream Control TransmissionProtocol (SCTP) protocol instance associated with a redundantlyimplemented SCTP endpoint, comprising the steps of: defining for theSCTP protocol instance, an idle mode of operation in which an SCTPmessage received from a peer SCTP protocol instance is forwarded to afurther SCTP protocol instance associated with the SCTP endpoint;determining an actual status of the mode of operation of the SCTPprotocol instance; and if the SCTP protocol instance is in the idle modeof operation, deciding according to a message type, whether or not toactively process a SCTP message received from a peer SCTP protocolinstance.
 17. The method according to claim 16, further comprising, ifthe received SCTP message is not actively processed: receiving from thefurther SCTP protocol instance associated with the SCTP endpoint, stateinformation for providing state consistency between the first and thefurther SCTP protocol instance; and adapting a state of the SCTPprotocol instance according to the received state information.
 18. Themethod according to claim 16, further comprising: defining for the SCTPprotocol instance, an active mode of operation, wherein if the SCTPprotocol instance is in the active mode of operation, the methodincludes: receiving a message originally sent by a peer SCTP protocolinstance from a further SCTP protocol instance providing redundancy ofthe SCTP endpoint; processing the received SCTP message; determining astate change of the SCTP protocol instance resulting from the processingof the SCTP message; and sending state information associated with thestate change to the further SCTP protocol instance.
 19. The methodaccording to claim 16, further comprising: receiving an indication of astate of availability of the further SCTP protocol instance; anddeciding to switch the mode of operation of the SCTP protocol instancefrom the active to the idle mode, or vice versa, according to thereceived indication of the state of availability of the further SCTPprotocol instance.
 20. The method according to claim 19, wherein theSCTP protocol instance receives multiple indications of states ofavailability of respective further SCTP protocol instances, and whereinthe step of deciding to switch the mode of operation is based on apreconfigured table and on said multiple states of availability of therespective further SCTP protocol instances.